For testing, I've been using something like the following framework:

• 2025-12-29-pelican-test-framework.tar.gz

Of special note is the ./certs/.init.sh script, which provides an example how to create and use a CA. (You'll probably want to modify environment.cfg to refer to your own container images.)

Once you've got the containers up and running, you can try things like:

# Check for errors in the entrypoint script.
$ docker logs pelican-director-1 2>&1 | less

# Check whether we need to skip certificate validation.
$ docker exec -it pelican-director-1 bash -il
[root@director pelican]# curl https://registry:8444/
<a href="/view/">Found</a>.

[root@director pelican]# curl https://origin-0:8444/
<a href="/view/">Found</a>.

[root@director pelican]# curl https://cache-0:8444/
<a href="/view/">Found</a>.

@jhiemstrawisc

I did a quick poll and we're all using the VSCode devcontainers extension, which doesn't go through the entrypoints defined here. At least in my case, I also rely on Pelican to generate a new CA on its first run whenever I need to restart my container, at which point it's too late to do something clever with entrypoints.

To quote Luke Skywalker, "Every word of what you just said was wrong."

Obviously, not literally so, but… I am aware of no production service that is expected to create its own certificate or CA on startup (or restart), and Pelican's released container images use these entrypoints, so the notion that there's a developer out there that doesn't go through these entrypoints is… What are they actually testing?